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REMARKS 

The Examiner has rejected Claims 1-2, 4-13, 15-23, 39-40, 44-51 and 53-54 under 
35 U.S.C. 103(a) as being unpatentable over Slivka et al. (U.S. Patent No. 6,256,668), in 
view of Meyerson (U.S. Patent Publication No. 2002/0184619), in further view of Apfel 
et al. (U.S. Patent No. 5,974,454). The Examiner has also rejected Claims 24-26, 29-38, 
43 and 52 under 35 U.S.C. 103(a) as being unpatentable over Slivka, in view of 
Meyerson and Apfel, and further in view of "Understanding UPnP™: A Whitepaper" 
(June 200, published by the UPnP™ Forum). Applicant respectfully disagrees with such 
rejections, especially in view of the amendments made hereinabove to each of the 
independent claims. 

With respect to each of the independent claims, the Examiner has relied on Col. 2, 
lines 37-43; and Col, 3, lines 8-13 and 21-23 in Slivka to make a prior art showing of 
applicant's claimed "appliance status table recording a status report periodically received 
from a status daemon autonomously operating on each of a plurality of network 
appliances, each status report containing health and status information and application- 
specific data pertaining to autonomous configuration and management of each network 
appliance" (see the same or similar, but not necessarily identical language in each of the 
independent claims). 

Applicant respectfully asserts that such excerpts from Slivka teach that "an update 
service computer conducts an automatic inventory of the computer software on the user 
computer" (see specifically CoL 2, lines 36-39). Thus, in Slivka the update service 
computer retrieves the inventory on the user computer, which clearly does not meet 
applicant's claim language, namely that "a status report [is] periodically received from a 
status daemon autonomously operating on each of a plurality of netw ork appliances" 
(emphasis added). 

In addition, with respect to each of the independent claims, the Examiner has 
relied on Steps 62-66, 94, and 106-108 along with CoL 10, lines 13-24 in Slivka to make 
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a prior art showing of applicant's claimed technique ct wherein each network appliance, 
prior to sending the status report, executes at least one initial plug-in; and, after installing 
the installable components, executes at least one post-plug-in " Applicant respectfully 
asserts that Slivka only teaches that the "update service computer launches [the] service 
update application" (step 62 in Figure 4A) prior to the "user update application send[ing 
the] inventory data to the service update application" (step 70 of Figure 4A). Thus, in 
Slivka only the update service computer launches an application, which clearly does not 
meet applicant's claimed technique "wherein each network appliance, prior to sending 
the status report, executes at least one initial plug-in" (emphasis added). 

In addition, Slivka also fails to meet applicant's claimed technique "wherein each 
network appliance, ..after installing the installable components, executes at least one 
post-plug-in." In particular, Slivka only teaches that the service update application 
downloads and installs all computer software chosen [on the user computer] (step 94 in 
Figure 4B; step 106 in Figure 5; and Col. 10, lines 13-24). Thus, Slivka only teaches that 
the updates themselves are installed, and not that " after installing the installable 
components, [each network appliance] executes at least one post-plug-in," as applicant 
claims (emphasis added). 

Still with respect to each of the independent claims, the Examiner has relied on 
Steps 62-66 and the corresponding portion of the description in Slivka to make a prior art 
showing of applicant's claimed technique "wherein the at least one initial plug-in 
monitors the status daemon to determine if the status daemon is running, and restart the 
status daemon if it is determined that the status daemon is not running." Applicant notes 
that steps 62-66 in Slivka only teach that the "update service computer launches [the] 
service update application" (step 62 in Figure 4A) prior to the "user update application 
sendfing the] inventory data to the service update application" (step 70 of Figure 4A). 
Thus, in Slivka, only the update service computer launches a service update application, 
First, applicant respectfully asserts that an update service computer launching a program, 
as in Slivka, does not meet applicant's claimed initial plug-in which is executed by each 
network appliance, when read in the context claimed. Second, in Slivka, the program 
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that is launched by the update service computer is the service update application, which 
clearly does not meet applicant's claimed "initial plug-in [that] monitors the Status 
daemon to determine if the status daemon is running, and restart the status daemon if it is 
determined that the status daemon is not running" (emphasis added). 

Still yet, with respect to each of the independent claims, the Examiner has relied 
on Col. 3, lines 66 et seq. and Col. 6, lines 63 et seq. in Apfel to make a prior art showing 
of applicant's claimed technique 'therein the catalog further includes. . .a type indicator 
indicating whether each installable component is a package or a file." Applicant 
respectfully asserts that the excerpts in Apfel relied on by the Examiner only teach a 
package server and that ApfePs "invention may also be implemented in combination with 
other program modules." In addition, after careful review of the entire Apfel reference, 
applicant notes that Apfel only discloses upgrade packages, such that applicant's claimed 
' Ivpe indicator indicating whether each installable component is a package or a file" is 
not even suggested (emphasis added). 

To establish a prima facie case of obviousness, three basic criteria must be met. 
First, there must be some suggestion or motivation, either in the references themselves or 
in the knowledge generally available to one of ordinary skill in the art, to modify the 
reference or to combine reference teachings. Second, there must be a reasonable 
expectation of success. Finally, the prior art reference (or references when combined) 
must teach or suggest all the claim limitations. The teaching or suggestion to make the 
claimed combination and the reasonable expectation of success must both be found in the 
prior art and not based on applicant's disclosure. In re Vaeck 947 F.2d 488, 20 USPQ2d 
1438 (Fed.Cir.1991). 

Applicant respectfully asserts that at least the third element of the prima facie 
case of obviousness has not been met, since the prior art references, when combined, fail 
to teach or suggest all of the claim limitations, as noted above. Nevertheless, despite 
such paramount deficiencies and in the spirit of expediting the prosecution of the present 
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application, applicant has substantially incorporated the subject matter of Claim 2 et al. 
along with additional language into each of the independent claims. 

With respect to the subject matter of Claim 2 et ah, the Examiner has relied on 
Col 13, lines 9-15; CoL 2, lines 65-67; and Col. 3, lines 5-8 in Slivka to make a prior art 
showing of applicant's claimed "network operations center establishing a secure session 
with each network appliance" (see the same or similar, but not necessarily identical 
language presently incorporated into each of the independent claims). In making such a 
rejection, it seems that the Examiner has relied on Slivka's disclosure of a Secure 
Software Distribution (SSD) process to meet applicant's specific claim language. 
Applicant notes, however, that the SSD process disclosed in Slivka only relates to a 
process by which "new versions of software. . .can be verified as being secure by the 
server application. . .and then verified again by the client application" where the new 
versions of software are "sent across a public network channel" (see CoL 13, lines 19- 
24). Thus, the SSD process in Slivka does not use a "secure session" as applicant claims, 
but instead only utilizes a public network channel and then verifies the software at the 
server and the client. 

To further clarify such distinction, applicant has included the following 
highlighted claim language with the subject matter of Claim 2 et al. s as presently 
incorporated into each of the independent claims: 

"a network operations center establishing a secure session with each 
network applianc e utilizing Secure Hypertext Transfer Protocol (HTTPSV 7 (see 
the same or similar, not necessarily identical language presently incorporated into 
each of the independent claims). 

Still yet, applicant has further included the following claim language into each of 
the independent claims: 
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"wherein the appliance status table further records a user identifier 
associated with the network appliance from which the status report is received and 
a time the status report is received." 

Applicant respectfully asserts that simply nowhere in the prior art references 
relied on by the Examiner is there any disclosure of an appliance status table that records 
a status report received from a status daemon that autonomously operates on each 
network appliance, let alone where such appliance status table records user identifiers and 
times associated with received status reports, in the context presently claimed by 
applicant. 

Since at least the third element of the prima facie case of obviousness has not 
been met, a notice of allowance or a proper prior art showing of all of the claim 
limitations, in the context of the remaining elements, is respectfully requested. 

Still yet, applicant brings to the Examine*' s attention the subject matter of new 
Claims 55-56 below, which are added for full consideration: 

"wherein the status report contains machine-specific data including a load 
on a processor and available disk space associated with each network appliance, 
and the application-specific data includes a number of e-mails passing through 
each of a plurality of network devices" (see Claim 55); and 

"wherein the installable components for being installed on each network 
appliance are installed on each network appliance according to a location 
identified in a corresponding file information subdirectory of the network 
operations center 3 ' (see Claim 56). 

A notice of allowance or a specific prior art showing of all of applicant's claim 
limitations, in combination with the remaining claim elements, is respectfully requested. 
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Thus, all of the independent claims are deemed allowable. Moreover, the 
remaining dependent claims are further deemed allowable, in view of their dependence 
on such independent claims. 

In the event a telephone conversation would expedite the prosecution of this 
application, the Examiner may reach the undersigned at (408) 505-5100. The 
Commissioner is authorized to charge any additional fees or credit any overpayment to 
Deposit Account No. 50-1351 (Order No. NAI1P375/01. 086.01), 
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